The buffer is sized by the caller using a separate lance_dataset_index_segment_count() call. The implementation reloads the snapshot independently in each call (snap.load_indices() is invoked twice), and the inner loop writes count * 16 bytes without any capacity check.

The C++ wrapper makes this two-call pattern explicit:

uint64_t count = index_segment_count(index_name);  // call #1: snapshot load
std::vector<std::array<uint8_t, 16>> out(count);
... lance_dataset_index_segments(...)              // call #2: snapshot load

Between call #1 and call #2, a concurrent writer could commit a new segment for the same logical index — exactly the distributed-build use case mentioned in the follow-ups section of the PR description. The second snapshot would then return more segments than the first, and the inner loop at src/index.rs:255–260 would overrun the caller's buffer:

for (i, seg) in segments.iter().enumerate() {
    let bytes = seg.uuid.as_bytes();
    unsafe {
        std::ptr::copy_nonoverlapping(bytes.as_ptr(), out_uuids.add(i * 16), 16);
    }
}

There is no SAFETY: comment justifying why out_uuids is large enough.

Possible Fixes

Adopt the well-established "capacity in, count out" FFI pattern (commonly seen in raw C APIs that fill caller-provided buffers):

int32_t lance_dataset_index_segments(
    const LanceDataset* dataset,
    const char* index_name,
    uint8_t* out_uuids,
    size_t capacity,        /* bytes available in out_uuids */
    uint64_t* out_count     /* how many UUIDs were actually written */
);

Reuse LANCE_ERR_INVALID_ARGUMENT (or introduce a new sentinel — the codebase currently has 8: LANCE_ERR_INVALID_ARGUMENT, LANCE_ERR_IO, LANCE_ERR_NOT_FOUND, LANCE_ERR_DATASET_ALREADY_EXISTS, LANCE_ERR_INDEX, LANCE_ERR_INTERNAL, LANCE_ERR_NOT_SUPPORTED, LANCE_ERR_COMMIT_CONFLICT) when capacity < segments.len() * 16. This also lets callers do single-shot retrieval with a guess and re-allocate if needed, removing the two-snapshot anti-pattern entirely.

Lighter-weight alternative: have a single Rust call return the count and a heap-allocated buffer with the segments. The codebase already exposes lance_free_string for CString-style strings; an analogous lance_free_uuid_buffer (or generic lance_free_bytes) would be a small, well-scoped addition. This eliminates caller-side sizing altogether at the cost of an extra allocation.

The with_index_segments(...) call is placed inside if let Some(n) = &self.nearest { ... }:

if let Some(n) = &self.nearest {
    scanner.nearest(&n.column, n.query.as_ref(), n.k as usize)?;
    ...
    if let Some(segments) = &self.index_segments {
        scanner.with_index_segments(segments.clone())?;
    }
}

If a caller invokes lance_scanner_set_index_segments(...) but never calls lance_scanner_nearest(...), the segment restriction is silently ignored — no error, no warning. For a distributed-query worker scanning the wrong segments, this is a correctness footgun.

Recommended fix. Either:

1. Validate at materialize time — return an error if index_segments.is_some() && nearest.is_none() with a message such as "index_segments requires nearest() to be configured".
2. Validate at setter time — in lance_scanner_set_index_segments, reject if s.nearest.is_none() and document the ordering requirement (consistent with the project's existing fail-fast guards such as the if k == 0 { ... } check inside scanner_nearest_inner).

Option 1 is more flexible (allows a builder to set segments before nearest); option 2 fails earlier and is closer to the rest of the file's style.

lance_dataset_index_count excludes system indexes (!is_system_index). The new lance_dataset_index_segment_count does not. If a system index ever shares a name with a user-visible index, the count silently includes it and lance_dataset_index_segments emits its UUIDs, which a worker may then attempt to query.

ditto